idnits 2.17.1 draft-groves-clue-latent-config-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6871]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 26, 2014) is 3741 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6501' is mentioned on line 100, but not defined == Missing Reference: 'RFC4574' is mentioned on line 190, but not defined == Unused Reference: 'RFC2119' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 530, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-05 == Outdated reference: A later version (-08) exists of draft-kyzivat-clue-signaling-05 == Outdated reference: A later version (-04) exists of draft-presta-clue-protocol-03 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE C. Groves, Ed. 3 Internet-Draft W. Yang 4 Intended status: Informational R. Even 5 Expires: July 30, 2014 Huawei 6 January 26, 2014 8 CLUE and latent configurations 9 draft-groves-clue-latent-config-00 11 Abstract 13 This document proposes to use Latent Configurations as described by 14 the SDP media capability negotiation framework [RFC6871] for the 15 description and negotiation of CLUE encodings. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 30, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Latent Configurations and CLUE . . . . . . . . . . . . . . . 3 53 2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. Messaging . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.3. Correlation . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.4. Returning an Answer . . . . . . . . . . . . . . . . . . . 5 57 2.5. Interworking . . . . . . . . . . . . . . . . . . . . . . 5 58 2.6. Relation to BUNDLE . . . . . . . . . . . . . . . . . . . 6 59 2.7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 67 8.2. Informative References . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 One of the issues faced in CLUE is how to describe the encodings 73 associated with the Advertised Captures. It was recently decided 74 that this encoding information would not be described in CLUE itself. 75 This means that other methods such as the use of SDP are required to 76 transmit this encoding information. When considering the use of SDP 77 (and in particular the use of SDP Offer/Answer) it should be 78 recognized that there is a semantic difference between a CLUE 79 encoding and an SDP media stream description. Given the nature of a 80 CLUE exchange the encoding represents a Capture/Stream that may occur 81 in the future (i.e. no resources are reserved) whereas a SDP Offer 82 typically relates to resources that are available at that point in 83 time. This does lead to complications when trying to describe CLUE 84 encodings using standard SDP O/A mechanisms. 86 An alternate approach to using the standard SDP O/A mechanisms for 87 describing CLUE encodings is to use the "SDP Capability Negotiation 88 framework" [RFC5939] and in particular to use the SDP Media 89 Capabilities Negotiation [RFC6871]. [RFC6871] defines "Latent 90 Configurations" as a means to describe media streams that may be used 91 in the future. 93 2. Latent Configurations and CLUE 95 The sections below discuss different aspects and benefits of using 96 Latent Configurations to describe CLUE encodings. 98 2.1. Semantics 100 [RFC6501] defines a Latent Configuration as: 102 A latent configuration indicates which combinations of 103 capabilities could be used in a future negotiation for the 104 session and its associated media stream components. Latent 105 configurations are neither ready for use nor offered for actual 106 or potential use in the current offer/answer exchange. Latent 107 configurations merely inform the other side of possible 108 configurations supported by the entity. Those latent 109 configurations may be used to guide subsequent offer/answer 110 exchanges, but they are not offered for use as part of the 111 current offer/answer exchange. 113 From the above description it can be seen that the semantic of a 114 Latent Configurations closely matches a CLUE message flow. I.e. A 115 set of possible Captures/Encodings (e.g. configurations) are 116 Advertised, the receiver can choose particular Captures/Encodings and 117 then the actual media stream is subsequently established. Therefore 118 the authors believe that use of latent configurations is a good 119 semantic fit with CLUE to describe the encodings. 121 2.2. Messaging 123 It has been recognized that CLUE Advertisements may contain a large 124 number of Captures and as there may be multiple encodings per capture 125 potentially a larger number of encodings. 127 Section 4.2 of CLUE signaling draft [I-D.kyzivat-clue-signaling] 128 indicates the CLUE Provider uses an "m" line for each separate 129 encoding and utilizes the "a=inactive", "a=sendonly" and "a=recvonly" 130 to manage when the media flows are instantiated. 132 This means that ports must be allocated for these "m" lines and the 133 SDP Offer/Answer [RFC3264] rules regarding maintaining these "m" 134 lines must be followed. 136 This results in potentially very large SDP descriptions containing 137 superfluous information that must be maintained for the life of the 138 session. 140 Latent Configurations allow a Provider to advertise potential media 141 without allocating multiple "m" lines or allocating ports for the 142 configurations. The SDP O/A model doesn't apply to Latent 143 Configurations which means that less data is sent over the life of a 144 session. 146 This allows a Provider to offer a basic media stream for immediate 147 use (i.e. an audio "m" line) and a list of latent configurations for 148 later use without the need for additional m-lines. This is described 149 by [RFC6871]: 151 A new attribute ("a=lcfg") specifies latent media stream 152 configurations when no corresponding media line ("m=") is 153 offered. An example is the offer of latent configurations for 154 video even though no video is currently offered. If the peer 155 indicates support for one or more offered latent configurations, 156 the corresponding media stream(s) may be added via a new offer/ 157 answer exchange. 159 AND 161 The "lcfg" attribute is defined as a media-level attribute since 162 it specifies a possible future media stream. However, the "lcfg" 163 attribute is not necessarily related to the media description 164 within which it is provided. Each media line in an SDP 165 description represents an offered simultaneous media stream, 166 whereas each latent configuration represents an additional stream 167 that may be negotiated in a future offer/answer exchange. 169 The use of Latent Configurations also means that resources aren't 170 tied up and can be allocated when they are needed. i.e. from 171 [RFC6871]: 173 A latent configuration represents a future capability; hence, the 174 "pt=" parameter is not directly meaningful in the "lcfg" 175 attribute because no actual media session is being offered or 176 accepted. It is permitted in order to tie any payload type 177 number parameters within attributes to the proper media format. 179 Therefore the authors believe that Latent Configurations provide a 180 clear benefit in terms of messaging size and complexity over normal 181 SDP Offer/Answer mechanism for Advertising CLUE encodings. 183 2.3. Correlation 185 One of the issues recognized in the CLUE work it that there needs to 186 be a correlation between the Captures signaled in CLUE and the 187 encodings defined in SDP. The encoding identity (EncodeID) is used 188 as an identity in CLUE. This same identity is then assigned to the 189 encoding in SDP. Currently [I-D.kyzivat-clue-signaling] indicates 190 that the label attribute [RFC4574] is used to identify the encoding 191 and that it is set per "m" line. 193 This same method can be used with Latent configurations as they allow 194 the use of SDP attributes in the configurations' description. 195 Section 3.3.8/[RFC6871] shows an example of the use of "label" with a 196 latent configuration, e.g. 198 a=lcfg:4 mt=video t=1 m=1 a=41,42 199 a=acap:41 label:13 200 a=acap:42 content:slides 202 The use of Latent Configurations does not require any new SDP 203 attributes to be defined in order for it to be used for CLUE 204 encodings. 206 2.4. Returning an Answer 208 A consumer upon receiving an SDP Offer containing CLUE related latent 209 configurations from the Provider could immediately send an SDP answer 210 with the configurations that it could support, i.e. section 3.3.6.1/ 211 [RFC6871]: 213 Potential and/or latent configuration attributes may be returned 214 within an answer SDP to indicate the ability of the answerer to 215 support alternative configurations of the corresponding 216 stream(s). 218 The consumer would then send a CLUE Configure indicating the Capture 219 Encodings it wants. The Provider can then subsequently offer actual 220 media streams for the encodings. 222 2.5. Interworking 224 One aspect to be considered is the level of adoption of the SDP media 225 capabilities negotiation framework in network entities. Whilst the 226 framework is not widely deployed it is supported by 3GPP (e.g. 227 [SDO-3GPP.24.292]) and is supported by the ITU-T (e.g. 228 [ITU.H248.80.2014] and [ITU.T38.2010]. 230 It must also be recognized that CLUE itself is something completely 231 new and clients and network equipment must be upgraded to support 232 CLUE signaling. Thus this equipment could also be upgraded to 233 support Latent Configurations at the same time. 235 In cases where a CLUEfull client sends SDP requesting a CLUE channel 236 and a number of latent configurations to a client that doesn't 237 support CLUE or the media capability framework, the receiving client 238 will ignore the attributes associated with the latent configuration 239 as per normal SDP behavior. Thus there are no interworking issues in 240 this case. 242 In cases where a CLUEfull client sends SDP requesting a CLUE channel 243 and a number of latent configurations to a client that doesn't 244 support CLUE but DOES support the media capability framework, the 245 receiving client would ignore the CLUE related attributes but could 246 respond with what latent configurations it could support. This would 247 allow the sender to decide if it wanted to offer subsequent media 248 streams. Again there are no interworking issues in this case. 250 In either of the above cases the session between the clients wouldn't 251 be forced to maintain "m" lines for media that would never be used. 253 2.6. Relation to BUNDLE 255 At its core BUNDLE is about using SDP to describe that several "m" 256 lines use the same IP Address/Port for the transport of RTP media. 257 If SDP O/A is being used to describe CLUE encodings then there is a 258 potential interaction in that the CLUE encoding "m" lines would all 259 be subject the BUNDLE procedures whether or not they were actually 260 used for media. 262 The use of Latent Configurations would simplify this interaction 263 because Latent Configurations do not allocate or specify ports. They 264 would not be subject to BUNDLE procedures. Once the use of BUNDLE is 265 established (i.e. for the base media streams), then only the media 266 streams (Capture Encodings) that have been chosen by the Consumer can 267 be added to the BUNDLE. 269 2.7. Open Issues 271 There are several issues that need to be clarified in [RFC6871] with 272 respect to latent configurations. 274 1. Latent configurations are specified as media level attributes and 275 thus may be associated with any m-line in an SDP O/A as they 276 don't really pertain to a particular media. There appears to be 277 no guidance as to with m-line they should be associated with in 278 the case of multiple m-line in a SDP Offer. 280 2. It's not clear from [RFC6871] what happens to latent 281 configurations when an endpoint decides to instantiate the latent 282 configuration as an m-line through an updated SDP Offer. 284 Section 3.4.4/[RFC6871] discusses modifying the session but has 285 minimal information. It is assumed by the authors that the 286 latent configuration is removed once instantiated. 288 3. It needs to be clarified whether [RFC6871] indicates that the SDP 289 Answerer SHOULD reply with the latent configurations it supports 290 or whether this is optional. If it's optional what does it mean? 292 4. [RFC6871] allows an SDP Answerer to reply with additional latent 293 configurations. However it doesn't specify what action the SDP 294 Offerer should take. This needs to be clarified. 296 3. Example 298 This section describes an example session establishment utilizing 299 CLUE and latent configurations. The Provider offers a base audio 300 stream, a CLUE channel (according to [I-D.ietf-mmusic-sctp-sdp] and 301 several latent configurations related to video captures. 303 v=0 304 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com 305 s= 306 c=IN IP4 host.anywhere.com 307 t=0 0 308 m=audio 49170 RTP/AVP 0 ; Base audio stream 309 a=rtpmap:0 PCMU/8000 311 ; CLUE channel establishment request 312 m=application 49172 SCTP 49172 313 a=setup:actpass 314 a=connection:new 315 a=sctpmap:49172 CLUE 1 317 ;Offered configurations 318 a=rmcap:1 H264/90000 ; this is needed for the m= 319 a=rmcap:2 VP8/90000 320 a=tcap:1 RTP/AVPF ; for the t= 321 a=acap:5 sendonly 322 a=acap:1 label:encoding1 323 a=lcfg:1 mt=video t=1 m=1|2 a=1,5 pt=1:100,2:101 324 a=acap:2 label:encoding2 325 a=lcfg:2 mt=video t=1 m=1|2 a=2,5 pt=1:102,2:103 326 a=acap:3 label:encoding3 327 a=lcfg:3 mt=video t=1 m=1|2 a=3,5 pt=1:104,2:105 328 a=acap:4 label:encoding4 329 a=lcfg:4 mt=video t=1 m=1|2 a=4,5 pt=1:106,2:107 331 Figure 1: Initial Offer 333 The receiver is CLUE capable and responds indicating support of the 334 CLUE channel and indicates the IP Address/Port where the Provider 335 should establish a connection to. It also indicates that it only 336 supports H264 encoding. 338 v=0 339 o=bob 2890844730 2890844730 IN IP4 host.example.com 340 s= 341 c=IN IP4 host.example.com 342 t=0 0 343 m=audio 49920 RTP/AVP 0 344 a=rtpmap:0 PCMU/8000 346 ; Accepted SCTP CLUE connection 347 m=application 54321 SCTP 54321 348 c=IN IP4 192.0.2.1 349 a=setup:passive 350 a=connection:new 351 a=sctpmap:54321 CLUE 1 353 ;Accepted configurations 354 a=rmcap:1 H264/90000 ; this is needed for the m= 355 a=tcap:1 RTP/AVPF ; for the t= 356 a=acap:5 sendonly 357 a=acap:1 label:encoding1 358 a=lcfg:1 mt=video t=1 m=1|2 a=1,5 pt=1:100 359 a=acap:2 label:encoding2 360 a=lcfg:2 mt=video t=1 m=1|2 a=2,5 pt=1:102 361 a=acap:3 label:encoding3 362 a=lcfg:3 mt=video t=1 m=1|2 a=3,5 pt=1:104 363 a=acap:4 label:encoding4 364 a=lcfg:4 mt=video t=1 m=1|2 a=4,5 pt=1:106 366 Figure 2: Answer 368 Author's note: In the signaling document the grouping framework 369 [RFC5888] is used to indicate the "m" lines that are under CLUE 370 control. It's not clear whether a=group:CLUE and a=mid is needed at 371 this stage or during the updated-Offer. It could be assumed that the 372 above latent configurations are related to CLUE due to the fact they 373 appear under the m=application SCTP/CLUE line. 375 On receipt of the SDP Answer the Provider establishes the SCTP 376 connection, performs CLUE version and capability negotiation (not 377 shown) and then sends the initial CLUE Advertisement. In it the 378 Provider advertises a single Capture Scene described by three video 379 captures (i.e. Left,Centre,Right) or a video capture of the entire 380 scene. 382 Author's note: According to the current CLUE protocol work 383 [I-D.presta-clue-protocol], it's the consumer that sends the first 384 Advertisement. The author believes that the Provider should send the 385 first Advertisement to align with the Offer. 387 +-----------------------|---------------------------------+ 388 | Capture Scene #1 | | 389 +-----------------------|---------------------------------+ 390 | VC1 | CaptureArea=Left | 391 | | EncodingGroup=EG1 | 392 | VC2 | CaptureArea=Centre | 393 | | EncodingGroup=EG2 | 394 | VC3 | CaptureArea=Right | 395 | | EncodingGroup=EG3 | 396 | VC4 | CaptureArea=All | 397 | | EncodingGroup=EG4 | 398 | CSE(VC1,VC2,VC3) | | 399 | CSE(VC4) | | 400 +-----------------------|---------------------------------+ 401 | EncodingGroups | | 402 +-----------------------|---------------------------------+ 403 | EG1 | EncodeID=encoding1 | 404 | EG2 | EncodeID=encoding2 | 405 | EG3 | EncodeID=encoding3 | 406 | EG4 | EncodeID=encoding4 | 407 +=======================+=================================+ 409 Figure 3: Advertisement 411 On receipt of the Advertisement the Consumer determines that it wants 412 the three video captures representing left/centre/right. It sends a 413 CLUE Configure to the Provider: 415 +-----------------------+---------------------------------+ 416 | VC1 | encoding1 | 417 | VC2 | encoding2 | 418 | VC3 | encoding3 | 419 +-----------------------|---------------------------------+ 421 Figure 4: Configure 423 On receipt of the CLUE Configure the Provider determines that the 424 Consumer wants to see VC1, VC2 and VC3 according to encoding1, 425 encoding2 and encoding3 respectively. The Provider then issues an 426 updated SDP Offer for three additional video streams. Note: The 427 latent configurations have been removed but the latent configuration 428 related to VC4/encoding4 could also be maintained if still available. 430 The grouping framework [RFC5888] is used to indicate that the 431 additional video streams are under CLUE control. 433 v=0 434 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com 435 s= 436 a=group:CLUE 1 2 3 437 c=IN IP4 host.anywhere.com 438 t=0 0 439 m=audio 49170 RTP/AVP 0 ; Base audio stream 440 a=rtpmap:0 PCMU/8000 442 ; CLUE channel estab. Req. 443 m=application 49172 SCTP 49172 444 a=setup:actpass 445 a=connection:new 446 a=sctpmap:49172 CLUE 1 448 ;Additional video streams 449 m=video 49174 RTP/AVPF 100 450 a=rtpmap:100 H264/90000 451 a=label:encoding1 452 a=mid:1 453 a=sendonly 455 m=video 49176 RTP/AVPF 102 456 a=rtpmap:102 H264/90000 457 a=label:encoding2 458 a=mid:2 459 a=sendonly 461 m=video 49178 RTP/AVPF 104 462 a=rtpmap:104 H264/90000 463 a=label:encoding3 464 a=mid:3 465 a=sendonly 467 Figure 5: Updated Offer 469 The Consumer then receives the Updated Offer and confirms with an 470 updated Answer. Media flow for the 3 video streams then starts to 471 flow. 473 4. Summary 475 The authors believe that the use of Latent Configurations is an ideal 476 way to indicate CLUE encoding information. It is proposed that the 477 use of Latent Configuration is the preferred way of describing CLUE 478 encoding information. 480 5. Acknowledgements 482 This template was derived from an initial version written by Pekka 483 Savola and contributed by him to the xml2rfc project. 485 6. IANA Considerations 487 It is not expected that the proposed changes present the need for any 488 IANA registrations. 490 7. Security Considerations 492 It is not expected that the proposed changes present any addition 493 security issues to the current framework. 495 8. References 497 8.1. Normative References 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, March 1997. 502 8.2. Informative References 504 [I-D.ietf-mmusic-sctp-sdp] 505 Loreto, S. and G. Camarillo, "Stream Control Transmission 506 Protocol (SCTP)-Based Media Transport in the Session 507 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-05 508 (work in progress), October 2013. 510 [I-D.kyzivat-clue-signaling] 511 Kyzivat, P., Xiao, L., Groves, C., and R. Hansen, "CLUE 512 Signaling", draft-kyzivat-clue-signaling-05 (work in 513 progress), September 2013. 515 [I-D.presta-clue-protocol] 516 Presta, R. and S. Romano, "CLUE protocol", draft-presta- 517 clue-protocol-03 (work in progress), November 2013. 519 [ITU.H248.80.2014] 520 International Telecommunications Union, "Usage of the 521 revised SDP offer / answer model with H.248", ITU-T 522 Recommendation H.248.80, 2014. 524 [ITU.T38.2010] 525 International Telecommunications Union, "Procedures for 526 real time Group 3 facsimile communication between 527 terminals using IP Networks", ITU-T Recommendation T.38, 528 2010. 530 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 531 June 1999. 533 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 534 with Session Description Protocol (SDP)", RFC 3264, June 535 2002. 537 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 538 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 540 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 541 Capability Negotiation", RFC 5939, September 2010. 543 [RFC6871] Gilman, R., Even, R., and F. Andreasen, "Session 544 Description Protocol (SDP) Media Capabilities 545 Negotiation", RFC 6871, February 2013. 547 [SDO-3GPP.24.292] 548 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 549 Centralized Services (ICS); Stage 3", 3GPP TS 24.292 550 10.11.0, June 2013. 552 Authors' Addresses 554 Christian Groves (editor) 555 Huawei 556 Melbourne 557 Australia 559 Email: Christian.Groves@nteczone.com 561 Weiwei Yang 562 Huawei 563 P.R.China 565 Email: tommy@huawei.com 566 Roni Even 567 Huawei 568 Tel Aviv 569 Isreal 571 Email: roni.even@mail01.huawei.com