CLUE C. Groves, Ed. Internet-Draft W. Yang Intended status: Informational R. Even Expires: July 30, 2014 Huawei January 26, 2014 CLUE and latent configurations draft-groves-clue-latent-config-00 Abstract This document proposes to use Latent Configurations as described by the SDP media capability negotiation framework [RFC6871] for the description and negotiation of CLUE encodings. 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/. 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 July 30, 2014. Copyright Notice Copyright (c) 2014 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 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. Groves, et al. Expires July 30, 2014 [Page 1] Internet-Draft CLUE and latent config January 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Latent Configurations and CLUE . . . . . . . . . . . . . . . 3 2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Messaging . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Correlation . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Returning an Answer . . . . . . . . . . . . . . . . . . . 5 2.5. Interworking . . . . . . . . . . . . . . . . . . . . . . 5 2.6. Relation to BUNDLE . . . . . . . . . . . . . . . . . . . 6 2.7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 6 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction One of the issues faced in CLUE is how to describe the encodings associated with the Advertised Captures. It was recently decided that this encoding information would not be described in CLUE itself. This means that other methods such as the use of SDP are required to transmit this encoding information. When considering the use of SDP (and in particular the use of SDP Offer/Answer) it should be recognized that there is a semantic difference between a CLUE encoding and an SDP media stream description. Given the nature of a CLUE exchange the encoding represents a Capture/Stream that may occur in the future (i.e. no resources are reserved) whereas a SDP Offer typically relates to resources that are available at that point in time. This does lead to complications when trying to describe CLUE encodings using standard SDP O/A mechanisms. An alternate approach to using the standard SDP O/A mechanisms for describing CLUE encodings is to use the "SDP Capability Negotiation framework" [RFC5939] and in particular to use the SDP Media Capabilities Negotiation [RFC6871]. [RFC6871] defines "Latent Configurations" as a means to describe media streams that may be used in the future. Groves, et al. Expires July 30, 2014 [Page 2] Internet-Draft CLUE and latent config January 2014 2. Latent Configurations and CLUE The sections below discuss different aspects and benefits of using Latent Configurations to describe CLUE encodings. 2.1. Semantics [RFC6501] defines a Latent Configuration as: A latent configuration indicates which combinations of capabilities could be used in a future negotiation for the session and its associated media stream components. Latent configurations are neither ready for use nor offered for actual or potential use in the current offer/answer exchange. Latent configurations merely inform the other side of possible configurations supported by the entity. Those latent configurations may be used to guide subsequent offer/answer exchanges, but they are not offered for use as part of the current offer/answer exchange. From the above description it can be seen that the semantic of a Latent Configurations closely matches a CLUE message flow. I.e. A set of possible Captures/Encodings (e.g. configurations) are Advertised, the receiver can choose particular Captures/Encodings and then the actual media stream is subsequently established. Therefore the authors believe that use of latent configurations is a good semantic fit with CLUE to describe the encodings. 2.2. Messaging It has been recognized that CLUE Advertisements may contain a large number of Captures and as there may be multiple encodings per capture potentially a larger number of encodings. Section 4.2 of CLUE signaling draft [I-D.kyzivat-clue-signaling] indicates the CLUE Provider uses an "m" line for each separate encoding and utilizes the "a=inactive", "a=sendonly" and "a=recvonly" to manage when the media flows are instantiated. This means that ports must be allocated for these "m" lines and the SDP Offer/Answer [RFC3264] rules regarding maintaining these "m" lines must be followed. This results in potentially very large SDP descriptions containing superfluous information that must be maintained for the life of the session. Groves, et al. Expires July 30, 2014 [Page 3] Internet-Draft CLUE and latent config January 2014 Latent Configurations allow a Provider to advertise potential media without allocating multiple "m" lines or allocating ports for the configurations. The SDP O/A model doesn't apply to Latent Configurations which means that less data is sent over the life of a session. This allows a Provider to offer a basic media stream for immediate use (i.e. an audio "m" line) and a list of latent configurations for later use without the need for additional m-lines. This is described by [RFC6871]: A new attribute ("a=lcfg") specifies latent media stream configurations when no corresponding media line ("m=") is offered. An example is the offer of latent configurations for video even though no video is currently offered. If the peer indicates support for one or more offered latent configurations, the corresponding media stream(s) may be added via a new offer/ answer exchange. AND The "lcfg" attribute is defined as a media-level attribute since it specifies a possible future media stream. However, the "lcfg" attribute is not necessarily related to the media description within which it is provided. Each media line in an SDP description represents an offered simultaneous media stream, whereas each latent configuration represents an additional stream that may be negotiated in a future offer/answer exchange. The use of Latent Configurations also means that resources aren't tied up and can be allocated when they are needed. i.e. from [RFC6871]: A latent configuration represents a future capability; hence, the "pt=" parameter is not directly meaningful in the "lcfg" attribute because no actual media session is being offered or accepted. It is permitted in order to tie any payload type number parameters within attributes to the proper media format. Therefore the authors believe that Latent Configurations provide a clear benefit in terms of messaging size and complexity over normal SDP Offer/Answer mechanism for Advertising CLUE encodings. 2.3. Correlation One of the issues recognized in the CLUE work it that there needs to be a correlation between the Captures signaled in CLUE and the encodings defined in SDP. The encoding identity (EncodeID) is used Groves, et al. Expires July 30, 2014 [Page 4] Internet-Draft CLUE and latent config January 2014 as an identity in CLUE. This same identity is then assigned to the encoding in SDP. Currently [I-D.kyzivat-clue-signaling] indicates that the label attribute [RFC4574] is used to identify the encoding and that it is set per "m" line. This same method can be used with Latent configurations as they allow the use of SDP attributes in the configurations' description. Section 3.3.8/[RFC6871] shows an example of the use of "label" with a latent configuration, e.g. a=lcfg:4 mt=video t=1 m=1 a=41,42 a=acap:41 label:13 a=acap:42 content:slides The use of Latent Configurations does not require any new SDP attributes to be defined in order for it to be used for CLUE encodings. 2.4. Returning an Answer A consumer upon receiving an SDP Offer containing CLUE related latent configurations from the Provider could immediately send an SDP answer with the configurations that it could support, i.e. section 3.3.6.1/ [RFC6871]: Potential and/or latent configuration attributes may be returned within an answer SDP to indicate the ability of the answerer to support alternative configurations of the corresponding stream(s). The consumer would then send a CLUE Configure indicating the Capture Encodings it wants. The Provider can then subsequently offer actual media streams for the encodings. 2.5. Interworking One aspect to be considered is the level of adoption of the SDP media capabilities negotiation framework in network entities. Whilst the framework is not widely deployed it is supported by 3GPP (e.g. [SDO-3GPP.24.292]) and is supported by the ITU-T (e.g. [ITU.H248.80.2014] and [ITU.T38.2010]. It must also be recognized that CLUE itself is something completely new and clients and network equipment must be upgraded to support CLUE signaling. Thus this equipment could also be upgraded to support Latent Configurations at the same time. Groves, et al. Expires July 30, 2014 [Page 5] Internet-Draft CLUE and latent config January 2014 In cases where a CLUEfull client sends SDP requesting a CLUE channel and a number of latent configurations to a client that doesn't support CLUE or the media capability framework, the receiving client will ignore the attributes associated with the latent configuration as per normal SDP behavior. Thus there are no interworking issues in this case. In cases where a CLUEfull client sends SDP requesting a CLUE channel and a number of latent configurations to a client that doesn't support CLUE but DOES support the media capability framework, the receiving client would ignore the CLUE related attributes but could respond with what latent configurations it could support. This would allow the sender to decide if it wanted to offer subsequent media streams. Again there are no interworking issues in this case. In either of the above cases the session between the clients wouldn't be forced to maintain "m" lines for media that would never be used. 2.6. Relation to BUNDLE At its core BUNDLE is about using SDP to describe that several "m" lines use the same IP Address/Port for the transport of RTP media. If SDP O/A is being used to describe CLUE encodings then there is a potential interaction in that the CLUE encoding "m" lines would all be subject the BUNDLE procedures whether or not they were actually used for media. The use of Latent Configurations would simplify this interaction because Latent Configurations do not allocate or specify ports. They would not be subject to BUNDLE procedures. Once the use of BUNDLE is established (i.e. for the base media streams), then only the media streams (Capture Encodings) that have been chosen by the Consumer can be added to the BUNDLE. 2.7. Open Issues There are several issues that need to be clarified in [RFC6871] with respect to latent configurations. 1. Latent configurations are specified as media level attributes and thus may be associated with any m-line in an SDP O/A as they don't really pertain to a particular media. There appears to be no guidance as to with m-line they should be associated with in the case of multiple m-line in a SDP Offer. 2. It's not clear from [RFC6871] what happens to latent configurations when an endpoint decides to instantiate the latent configuration as an m-line through an updated SDP Offer. Groves, et al. Expires July 30, 2014 [Page 6] Internet-Draft CLUE and latent config January 2014 Section 3.4.4/[RFC6871] discusses modifying the session but has minimal information. It is assumed by the authors that the latent configuration is removed once instantiated. 3. It needs to be clarified whether [RFC6871] indicates that the SDP Answerer SHOULD reply with the latent configurations it supports or whether this is optional. If it's optional what does it mean? 4. [RFC6871] allows an SDP Answerer to reply with additional latent configurations. However it doesn't specify what action the SDP Offerer should take. This needs to be clarified. 3. Example This section describes an example session establishment utilizing CLUE and latent configurations. The Provider offers a base audio stream, a CLUE channel (according to [I-D.ietf-mmusic-sctp-sdp] and several latent configurations related to video captures. v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 ; Base audio stream a=rtpmap:0 PCMU/8000 ; CLUE channel establishment request m=application 49172 SCTP 49172 a=setup:actpass a=connection:new a=sctpmap:49172 CLUE 1 ;Offered configurations a=rmcap:1 H264/90000 ; this is needed for the m= a=rmcap:2 VP8/90000 a=tcap:1 RTP/AVPF ; for the t= a=acap:5 sendonly a=acap:1 label:encoding1 a=lcfg:1 mt=video t=1 m=1|2 a=1,5 pt=1:100,2:101 a=acap:2 label:encoding2 a=lcfg:2 mt=video t=1 m=1|2 a=2,5 pt=1:102,2:103 a=acap:3 label:encoding3 a=lcfg:3 mt=video t=1 m=1|2 a=3,5 pt=1:104,2:105 a=acap:4 label:encoding4 a=lcfg:4 mt=video t=1 m=1|2 a=4,5 pt=1:106,2:107 Figure 1: Initial Offer Groves, et al. Expires July 30, 2014 [Page 7] Internet-Draft CLUE and latent config January 2014 The receiver is CLUE capable and responds indicating support of the CLUE channel and indicates the IP Address/Port where the Provider should establish a connection to. It also indicates that it only supports H264 encoding. v=0 o=bob 2890844730 2890844730 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 49920 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ; Accepted SCTP CLUE connection m=application 54321 SCTP 54321 c=IN IP4 192.0.2.1 a=setup:passive a=connection:new a=sctpmap:54321 CLUE 1 ;Accepted configurations a=rmcap:1 H264/90000 ; this is needed for the m= a=tcap:1 RTP/AVPF ; for the t= a=acap:5 sendonly a=acap:1 label:encoding1 a=lcfg:1 mt=video t=1 m=1|2 a=1,5 pt=1:100 a=acap:2 label:encoding2 a=lcfg:2 mt=video t=1 m=1|2 a=2,5 pt=1:102 a=acap:3 label:encoding3 a=lcfg:3 mt=video t=1 m=1|2 a=3,5 pt=1:104 a=acap:4 label:encoding4 a=lcfg:4 mt=video t=1 m=1|2 a=4,5 pt=1:106 Figure 2: Answer Author's note: In the signaling document the grouping framework [RFC5888] is used to indicate the "m" lines that are under CLUE control. It's not clear whether a=group:CLUE and a=mid is needed at this stage or during the updated-Offer. It could be assumed that the above latent configurations are related to CLUE due to the fact they appear under the m=application SCTP/CLUE line. On receipt of the SDP Answer the Provider establishes the SCTP connection, performs CLUE version and capability negotiation (not shown) and then sends the initial CLUE Advertisement. In it the Provider advertises a single Capture Scene described by three video captures (i.e. Left,Centre,Right) or a video capture of the entire scene. Groves, et al. Expires July 30, 2014 [Page 8] Internet-Draft CLUE and latent config January 2014 Author's note: According to the current CLUE protocol work [I-D.presta-clue-protocol], it's the consumer that sends the first Advertisement. The author believes that the Provider should send the first Advertisement to align with the Offer. +-----------------------|---------------------------------+ | Capture Scene #1 | | +-----------------------|---------------------------------+ | VC1 | CaptureArea=Left | | | EncodingGroup=EG1 | | VC2 | CaptureArea=Centre | | | EncodingGroup=EG2 | | VC3 | CaptureArea=Right | | | EncodingGroup=EG3 | | VC4 | CaptureArea=All | | | EncodingGroup=EG4 | | CSE(VC1,VC2,VC3) | | | CSE(VC4) | | +-----------------------|---------------------------------+ | EncodingGroups | | +-----------------------|---------------------------------+ | EG1 | EncodeID=encoding1 | | EG2 | EncodeID=encoding2 | | EG3 | EncodeID=encoding3 | | EG4 | EncodeID=encoding4 | +=======================+=================================+ Figure 3: Advertisement On receipt of the Advertisement the Consumer determines that it wants the three video captures representing left/centre/right. It sends a CLUE Configure to the Provider: +-----------------------+---------------------------------+ | VC1 | encoding1 | | VC2 | encoding2 | | VC3 | encoding3 | +-----------------------|---------------------------------+ Figure 4: Configure On receipt of the CLUE Configure the Provider determines that the Consumer wants to see VC1, VC2 and VC3 according to encoding1, encoding2 and encoding3 respectively. The Provider then issues an updated SDP Offer for three additional video streams. Note: The latent configurations have been removed but the latent configuration related to VC4/encoding4 could also be maintained if still available. Groves, et al. Expires July 30, 2014 [Page 9] Internet-Draft CLUE and latent config January 2014 The grouping framework [RFC5888] is used to indicate that the additional video streams are under CLUE control. v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= a=group:CLUE 1 2 3 c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 ; Base audio stream a=rtpmap:0 PCMU/8000 ; CLUE channel estab. Req. m=application 49172 SCTP 49172 a=setup:actpass a=connection:new a=sctpmap:49172 CLUE 1 ;Additional video streams m=video 49174 RTP/AVPF 100 a=rtpmap:100 H264/90000 a=label:encoding1 a=mid:1 a=sendonly m=video 49176 RTP/AVPF 102 a=rtpmap:102 H264/90000 a=label:encoding2 a=mid:2 a=sendonly m=video 49178 RTP/AVPF 104 a=rtpmap:104 H264/90000 a=label:encoding3 a=mid:3 a=sendonly Figure 5: Updated Offer The Consumer then receives the Updated Offer and confirms with an updated Answer. Media flow for the 3 video streams then starts to flow. Groves, et al. Expires July 30, 2014 [Page 10] Internet-Draft CLUE and latent config January 2014 4. Summary The authors believe that the use of Latent Configurations is an ideal way to indicate CLUE encoding information. It is proposed that the use of Latent Configuration is the preferred way of describing CLUE encoding information. 5. Acknowledgements This template was derived from an initial version written by Pekka Savola and contributed by him to the xml2rfc project. 6. IANA Considerations It is not expected that the proposed changes present the need for any IANA registrations. 7. Security Considerations It is not expected that the proposed changes present any addition security issues to the current framework. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.ietf-mmusic-sctp-sdp] Loreto, S. and G. Camarillo, "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-05 (work in progress), October 2013. [I-D.kyzivat-clue-signaling] Kyzivat, P., Xiao, L., Groves, C., and R. Hansen, "CLUE Signaling", draft-kyzivat-clue-signaling-05 (work in progress), September 2013. [I-D.presta-clue-protocol] Presta, R. and S. Romano, "CLUE protocol", draft-presta- clue-protocol-03 (work in progress), November 2013. Groves, et al. Expires July 30, 2014 [Page 11] Internet-Draft CLUE and latent config January 2014 [ITU.H248.80.2014] International Telecommunications Union, "Usage of the revised SDP offer / answer model with H.248", ITU-T Recommendation H.248.80, 2014. [ITU.T38.2010] International Telecommunications Union, "Procedures for real time Group 3 facsimile communication between terminals using IP Networks", ITU-T Recommendation T.38, 2010. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010. [RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010. [RFC6871] Gilman, R., Even, R., and F. Andreasen, "Session Description Protocol (SDP) Media Capabilities Negotiation", RFC 6871, February 2013. [SDO-3GPP.24.292] 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS); Stage 3", 3GPP TS 24.292 10.11.0, June 2013. Authors' Addresses Christian Groves (editor) Huawei Melbourne Australia Email: Christian.Groves@nteczone.com Weiwei Yang Huawei P.R.China Email: tommy@huawei.com Groves, et al. Expires July 30, 2014 [Page 12] Internet-Draft CLUE and latent config January 2014 Roni Even Huawei Tel Aviv Isreal Email: roni.even@mail01.huawei.com Groves, et al. Expires July 30, 2014 [Page 13]