idnits 2.17.1 draft-even-clue-sdp-clue-relation-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: ---------------------------------------------------------------------------- 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 (October 21, 2012) is 4204 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-05) exists of draft-even-clue-rtp-mapping-04 == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-06 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE WG R. Even 3 Internet-Draft Huawei 4 Intended status: Informational October 21, 2012 5 Expires: April 24, 2013 7 Signalling of CLUE and SDP offer/answer 8 draft-even-clue-sdp-clue-relation-01.txt 10 Abstract 12 This document describes the relation between the different CLUE 13 attributes as specified in the CLUE framework and the SDP attributes. 14 The document will discuss the issues with the CLUE call signalling in 15 order to keep the consistency between the Offer/answer state and the 16 CLUE state. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 24, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Capture attributes . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Encoding parameters . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 The CLUE framework[I-D.ietf-clue-framework] is used to specify the 67 information needed for creating a Telepresence call. The model 68 includes the Media capture information providing information about 69 content of the streams and can provide information about the spatial 70 information between streams based on the capture point and area of 71 capture. A capture scene includes media captures that are part of a 72 same scene e.g. room capture or presentation. 74 The other information defined in the framework is the Encoding 75 information providing information about the abilities of the 76 providers to send streams allowing a consumer to configure a capture 77 to a specific encoding. 79 The next sections will look at the capture attributes and the 80 encoding parameter and describe the relation to SDP [RFC4566]. 82 2. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC2119[RFC2119] and 87 indicate requirement levels for compliant RTP implementations. 89 3. Capture attributes 91 The media capture attributes provide static information about the 92 captures. This includes the content of information and can provide 93 spatial information in order to allow the "being there" experience. 94 The media capture attributes include the content describing the role 95 of the media capture, if the content is composed or switched and 96 spatial information providing the three dimensional position of the 97 streams. 99 The media capture content attribute is based on SDP content attribute 100 [RFC4796] The other attribute do not have similar SDP attributes. 102 When starting a call the initial offer may include more than one 103 media stream of a media type with a content attribute (e.g. offer 104 main and slide SDP content). In this case the advertisement will 105 also include media captures for main and slides. If the initial 106 offer did not provide content attribute there is no need to provide 107 it later assuming that if the answerer do not support CLUE protocol 108 it is not sure that he will support the content attribute [RFC4796] 109 As for the other attributes, there are no similar SDP attributes and 110 they provide information which can be used by TelePresence systems. 111 The media capture switched and composed attributes provide 112 information about the creation of the content. Using RTP/RTCP SRRC 113 and CSRC [RFC3550] can provide information about the content of the 114 media captures. 116 The CLUE framework [I-D.ietf-clue-framework] recommends using one 117 transport connection for each media type multiplexing using one RTP 118 session. This also makes it simple to add and remove media capture 119 by the consumer without a need for an [RFC3264] offer answer. 121 The exception is if the consumer prefers using a separate RTP non 122 multiplex session. In this case when adding or removing a media 123 capture there will be a need to have also an offer answer session to 124 specify the UDP port for the new RTP session or to close it. (note 125 that ICE exchange may be required too). The open question is what 126 should be done first, CLUE configuration or SDP offer/answer. 128 As can be seen there is minimal duplication between SDP and these 129 media capture attributes. There is a need to correlate between the 130 RTP streams and media captures; this is discussed in CLUE RTP mapping 131 [I-D.even-clue-rtp-mapping] 133 When multiplexing RTP streams in a single RTP session there is 134 probably no need for offer answer exchange when the consumer send a 135 new configuration. 137 4. Encoding parameters 139 A media capture can specify an encoding group that maps a media 140 capture to encoding parameters. The encoding parameters are used to 141 provide information about the ability of a CLUE endpoint to send 142 streams. An encoding group is composed of individual encodes that 143 may be used by a media capture to encode a stream as long as the 144 total values of the attributes used by the individual encodes in the 145 group do not exceed the group encode values. 147 The individual encode parameters include: maxBandwidth, maxH264Mbps, 148 maxWidth, maxHeight and maxFrameRate. The encoding group parameters 149 include MaxGroupBandWidth, MaxGroupH264Mbps, and for video 150 MaxBandWidth. Note that the use case is to provide information about 151 the send capabilities of the provider. 153 The max H264Mbps is H.264 specific and there is a similar parameters 154 in RFC6184 [RFC6184] but in RFC6184signals the receiver capability. 156 The maxFrameRate is similar to SDP framerate attribute, for maxWidth 157 and MaxHeight there are similar parameters in [RFC6236]. All these 158 parameters carried in SDP signal the receiver capability or requested 159 mode. 161 The maxBandwidth is similar to the SDP b=attribute and specifying 162 group and individual values can be partially done using the session 163 level and media level attributes. The major different again is that 164 the b= attribute is used to describe receiver capability, maximum 165 bandwidth it can receive. 167 The Media capture encoding information and SDP attribute are similar 168 but they indicate different types of limitations. While the Media 169 capture attributes are sender encoding capabilities the SDP ones 170 specify receiver capabilities. This is because of the different 171 usage. The SDP attributes are used by the receiver to indicate what 172 it can receive and decode. Still in H.264 the parameter sets are 173 used to convey some of the above parameters (like width and height) 174 and can be conveyed in SDP using sprop-parameter-sets or sprop-level- 175 parameter-sets. In general the "sprop" attributes are used to convey 176 sender capabilities. 178 The RFC3264 [RFC3264] offer/answer is used by the receiver to limit 179 or ask for a specific mode. Since the encoding parameters specify 180 limits on the sending side it may look like there is no correlation 181 problem. The next sections will look at the specific parameters and 182 see if this assumption is correct. 184 The CLUE maxBandWidth is limiting the maximum bandwidth that a sender 185 will use. The receiver can ask for higher or lower bandwidth based 186 on H.264 level or using the SDP "b" attribute. If asking for higher 187 than the CLUE value will limit and is asking for lower value the SDP 188 value will be the limiting factor. A change mid-call may happen for 189 example because of congestion. The endpoint must be aware of both 190 values. Note that bandwidth change using RTCP TMMBR [RFC5104] can 191 occur. If the previous bandwidth was higher than the CLUE 192 maxBandwidth and the new band width is lower the EP must use the 193 lowest bandwidth. Since the bandwidth in the offer and answer 194 provide information about receiver capabilities it means that if the 195 value is changed by an intermediary like an SBC the sender will know 196 that the receiver now have different value and act accordingly. 198 The maxH264Mbps and maxFrameRate show similar behavior to 199 maxBandwidth. 201 The CLUE maxWidth and maxHeight as sender capability and the image 202 attribute in SDP are both send and receive capability. The 203 recommendation if for using RFC6236 to negotiate these values and not 204 CLUE encoding. The maxH264Mbps and maxFrameRate can be sufficient to 205 provide compute limitations on the encoder side. 207 Conclusion - except for the maxWidth and maxHeight there is no 208 problem between the SDP and CLUE encoding values as long as SDP 209 attributes are used as receiver capabilities and the relation between 210 the two protocols is defined. Changing SDP values will not require a 211 change in CLUE advertisement or configuration and vice versa since 212 these parameters signal maximum values and not exact values. 214 5. Acknowledgements 216 place holder 218 6. IANA Considerations 220 TBD 222 7. Security Considerations 224 TBD. 226 8. References 228 8.1. Normative References 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, March 1997. 233 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 234 with Session Description Protocol (SDP)", RFC 3264, 235 June 2002. 237 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 238 Description Protocol", RFC 4566, July 2006. 240 8.2. Informative References 242 [I-D.even-clue-rtp-mapping] 243 Even, R. and J. Lennox, "Mapping RTP streams to CLUE media 244 captures", draft-even-clue-rtp-mapping-04 (work in 245 progress), September 2012. 247 [I-D.ietf-clue-framework] 248 Romanow, A., Duckworth, M., Pepperell, A., and B. Baldino, 249 "Framework for Telepresence Multi-Streams", 250 draft-ietf-clue-framework-06 (work in progress), 251 July 2012. 253 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 254 Jacobson, "RTP: A Transport Protocol for Real-Time 255 Applications", STD 64, RFC 3550, July 2003. 257 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 258 Protocol (SDP) Content Attribute", RFC 4796, 259 February 2007. 261 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 262 "Codec Control Messages in the RTP Audio-Visual Profile 263 with Feedback (AVPF)", RFC 5104, February 2008. 265 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 266 Payload Format for H.264 Video", RFC 6184, May 2011. 268 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 269 Attributes in the Session Description Protocol (SDP)", 270 RFC 6236, May 2011. 272 Author's Address 274 Roni Even 275 Huawei 276 Tel Aviv, 277 Israel 279 Email: roni.even@mail01.huawei.com