idnits 2.17.1 draft-hansen-clue-sdp-interaction-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4078 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-09 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE R. Hansen 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track February 25, 2013 5 Expires: August 29, 2013 7 SDP and CLUE message interactions 8 draft-hansen-clue-sdp-interaction-01 10 Abstract 12 This document attempts to help resolve some of the complexities of 13 interaction between SDP and CLUE messages in call flows by providing 14 some strategies and some suggested syntax. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 29, 2013. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Initial Assumptions . . . . . . . . . . . . . . . . . . . . . . 3 53 4. The CLUE framework: dividing the information between SDP 54 and CLUE messaging . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1. CLUE information principally in CLUE channel . . . . . . . 4 56 4.2. Media encoding/decoding information in SDP, media 57 content information in CLUE messaging . . . . . . . . . . . 4 58 5. Interdependence of SDP and CLUE negotiation . . . . . . . . . . 6 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 63 Appendix A. Changes From Draft -00 . . . . . . . . . . . . . . . . 8 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 One issue that has repeatedly come up in the development of CLUE is 69 the interconnected nature of many of the issues - making decisions in 70 any one area requires that decisions are made in other areas. One 71 particularly problematic area has been that of producing call flows: 72 many of the decisions that need to be made revolve around how offer/ 73 answer exchanges and CLUE messages will interact, but without a good 74 understanding of what will be in SDP and what will be in CLUE these 75 decisions have been difficult to make. 77 In the hope of resolving some of these issues and allowing us to make 78 more progress on the subject of call flows and CLUE signalling 79 generally this draft addresses two issues that are hopefully not 80 dependent on decisions in other areas, both aspects of the 81 relationship between CLUE signalling and SDP. Hopefully this draft 82 will either provoke discussion, or document decisions that people 83 feel are obvious but aren't currently reflected in writing. 85 2. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119] and 90 indicate requirement levels for compliant implementations. 92 3. Initial Assumptions 94 This section enumerates a few assumptions based on previous 95 discussion which are, at this stage, hopefully uncontroversial. 97 CLUE information such as capture descriptions are unsuitable for SDP, 98 and as such there will be an alternate method for sending CLUE 99 messages end to end. In a call scenario where both sides wish to 100 send and receive this CLUE negotiation takes the form of two 101 independent, uni-directional exchanges; on each exchange one device 102 provides its send capabilities while the other side determines what 103 it wishes to receive. 105 This CLUE negotiation will never enable or require a call to exceed 106 boundaries negotiated in SDP. This most obviously applies to 107 bandwidth, both for the total call and for negotiated sessions, but 108 also means that codec-specific limitations such as the maximum number 109 of H.264 macroblocks a second a receiver can process MUST be 110 respected. 112 4. The CLUE framework: dividing the information between SDP and CLUE 113 messaging 115 The CLUE Framework [I-D.ietf-clue-framework] defines the information 116 that will be needed to successfully negotiate a CLUE call, but does 117 not define the mechanism by which this information is conveyed. This 118 section provides two options for dividing this information between 119 SDP and CLUE signalling, without proposing explicit signalling for 120 either channel (merely what information needs to be conveyed in 121 each). 123 4.1. CLUE information principally in CLUE channel 125 One approach that has been a major part of CLUE discussions has been 126 to make no significant additions to SDP, and continue to use it only 127 for the negotiation of RTP sessions. The sessions are then 128 potentially subdivided into multiple streams using CLUE signalling. 129 In this model standard SDP signalling provides the envelope within 130 which CLUE negotiates the number and content of multiple streams. 132 This method has a number of advantages - there is no need for 133 additional SDP syntax, making interoperability with existing devices 134 simple and concentrating new signalling in a single location (the 135 CLUE negotiation). There is also clear separation of 136 responsibilities between SDP and CLUE: as normal SDP negotiates the 137 specifics of the RTP sessions: address and ports, supported codecs, 138 receive maxima and so on, while CLUE messaging then specifies how 139 many streams are to be multiplexed on a port, details for 140 demultiplexing, content of those streams, encoding limits and so on. 141 The only necessary addition to the SDP would be a label [RFC4574] 142 attribute per media line to allow CLUE messaging to identify them. 144 Unfortunately, there are some downsides to this approach. The 145 primary one is that all multiplexing of streams is entirely dependant 146 on the CLUE channel - as such this is not a method applicable to 147 other applications. Since other groups within the IETF have an 148 interest in such multiplexing for reasons other than enabling 149 telepresence scenarios they would have to invent other methods for 150 negotiating similar multiplexing - both inefficient, and likely 151 problematic when CLUE and some other solution involving 152 multistreaming are both used in the call scenario. 154 4.2. Media encoding/decoding information in SDP, media content 155 information in CLUE messaging 157 An alternative approach is to divide the information in the CLUE 158 Framework [I-D.ietf-clue-framework] into the information specific to 159 encoding and decoding RTP streams, and the content of those streams. 161 On the advertising side this split is fairly natural: most of the 162 information in the framework relates to the number, content, physical 163 dimensions and simultaneity of the media captures available, 164 information related to the contents of the media streams rather than 165 the streams themselves. In contrast, the encoder and encoder group 166 information gives the limits on the media streams the sender can 167 provide, with parameters such as bandwidth, max h.264 macroblocks per 168 second and other parameters relevant to SDP. These are defined as 169 sender limitations rather than receiver ones and so are not directly 170 analogous to existing SDP parameters, but are better suited to SDP 171 than CLUE. 173 When it comes to receiver selection the separation between parameters 174 that logically should be in CLUE and should be in SDP is no longer so 175 clean-cut, as the receiver must specify capture encodings, choosing 176 both which captures they wish to receive and the media limitations on 177 such streams. The latter limitations are obviously suited to SDP, 178 but information about captures is more relevant to the CLUE channel. 179 The CLUE-specific information, however, is limited to simply 180 selecting a capture for the stream. 182 The ability to describe the sender's encoder limitations for 183 multiplexed streams along with the receiver's selection of those 184 streams and the media limitations, SSRCs and other demultiplexing 185 information are all requirements that are not specific to CLUE; 186 having them in SDP means that a consistent mechanism can be used by 187 CLUE as well as by other call scenarios wishing to support additional 188 media streams in this fashion. Capture information, in contrast, is 189 CLUE-specific and as such is sensible to keep in the CLUE channel. 190 The CLUE channel will also reference the SDP, linking captures to 191 encoding capabilities and identifying which capture is desired for 192 each stream. This split of information means that any change in 193 capture information on the part of a sender does not necessitate an 194 offer/answer exchange of SDP if there is no corresponding change to 195 the encoding capabilities of that sender - only a new CLUE 196 advertisement is required. 198 This approach leads to a number of dependencies between the SDP and 199 CLUE messages - the sender must define which captures and capture 200 scenes are usable with which streams/encodings, while the receiver 201 must define what capture they wish to receive with a particular 202 encoding. These could take the form of references in SDP to CLUE, 203 references in CLUE to SDP or references in each to the other. 204 However, this draft proposes that all such references MUST be from 205 CLUE messages to SDP, not the other way around. By ensuring all 206 depenencies are unidirectional it reduces the complexity of 207 integrating the two signalling methods. There are multiple reasons 208 for having references be CLUE->SDP and not the other way around: one 209 is that logically CLUE is providing metadata about the contents of 210 streams that are negotiated in SDP, so it makes sense for CLUE to be 211 dependent on SDP and not visa-versa. Another is that middle boxes 212 wishing to monitor or alter SDP can then do so without necessarily 213 needing to involve themselves in the CLUE channel as SDP remains 214 self-contained. 216 5. Interdependence of SDP and CLUE negotiation 218 With separate negotiation of SDP and CLUE there is the question of 219 how to deal with dependencies between these two channels. The number 220 of dependancies depends on how the information defined in the CLUE 221 Framework [I-D.ietf-clue-framework] is split between SDP and CLUE, as 222 discussed in the previous section, but even in the case where all new 223 information is in CLUE there will still be some dependencies as it 224 will be necessary to determine which m-lines the CLUE signalling is 225 referring to. However, because we have two signalling methods 226 changes that require alterations in both CLUE and SDP are no longer 227 atomic: one message will be processed before the other. There has 228 been debate within the working group about how this will be dealt 229 with, as such a decision has significant effect upon call flows. 231 This draft proposes that CLUE messages and SDP messages should be 232 independent: parameters in CLUE messages MAY exceed values negotiated 233 in SDP, or may make reference to SDP contents not present in the most 234 recent offer/answer exchange. Without this provision, SDP and CLUE 235 messages become part of a single negotiation, and a change on either 236 by either side may necessitate an exchange of the other message type. 237 For instance, removing stream information from SDP might first 238 necessitate sending a new CLUE message removing the references to 239 this stream. The state machine required to ensure validity of 240 negotiation will be complicated, and there will be a number of 241 invalid states which must be avoided. This is further complicated by 242 the fact that, even if both ends of a call obey the constraints to 243 ensure validity, a middle box may choose to rewrite an SDP such that 244 an invalid state is reached. 246 Making the two message types independent significantly reduces the 247 complexity of the state machines required. And with the message 248 flows independent there is no way for an invalid state to occur when 249 the two negotiations contain contradictory information. A cost of 250 this is that endpoints will now need to deal with the fact that CLUE 251 messages may contain parameters exceeding those negotiated in SDP, or 252 referencing SDP content that does not exist. However, this is 253 analogous to an issue endpoints already deal with in SDP. For 254 instance, the sum of bandwidth parameters for various m-lines can 255 exceed the overall session bandwidth. Not only is this not invalid, 256 but it can be desirable, as it allows the sender to prioritise 257 streams. What can be sent for any device is simply the intersection 258 of what is permitted by the most recent SDP offer/answer, and the 259 outcome of the CLUE negotiation; implementations should ignore 260 references to entities in the other negotiation that do no exist. 262 This does not mean that there will be no interaction between SDP and 263 CLUE messaging - a device wishing to add a new stream may well need 264 to update both their SDP and their CLUE negotiations. However, there 265 is no fixed order in which this must be done and no requirement for 266 them to be updated in a particular order or fashion; it is left to 267 the implementation to renegotiate the channels as it sees fit. If 268 updates to both negotiations are required for a new stream to be 269 added, then the new stream will not be available until both 270 renegotiations are complete - the completion of the first 271 renegotiation will have no effect. 273 6. Security Considerations 275 This draft only addresses how best to split information between SDP 276 and CLUE signalling and the interdependencies between these two 277 methods of signalling, it does not define the signalling or 278 information itself. As such this draft should require no additional 279 security considerations. 281 7. References 283 7.1. Normative References 285 [I-D.ietf-clue-framework] 286 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 287 for Telepresence Multi-Streams", 288 draft-ietf-clue-framework-09 (work in progress), 289 February 2013. 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, March 1997. 294 7.2. Informative References 296 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 297 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 299 Appendix A. Changes From Draft -00 301 o Reordered main sections, as in the discussion about 302 interdependence of SDP and CLUE is is useful to reference the 303 split between CLUE and SDP. 304 o Added more detail to the argument of why dependencies should be 305 CLUE->SDP and not the other way around or in both directions. 306 o Fixed spelling issues and did some minor rewording. 308 Author's Address 310 Robert Hansen 311 Cisco Systems 312 San Jose, CA 95134 313 USA 315 Email: rohanse2@cisco.com